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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal and the present application is 
CardinalConrimerce Corporation (fomnally CardinalCommerce.com, Inc.), by way of an 
Assignment recorded in the U.S. Patent and Trademark Office at Reel 010617, Frame 
0479. 

II. STATEMENT OF RELATED APPEALS AND INTERFERENCES 

There are no prior or pending appeals, interferences or judicial proceedings, 
known to Appellant, Appellant's representative, or the Assignee, that may be related to, 
or which will directly affect or be directly affected by or have a bearing upon the Board's 
decision in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 23, 24, 26-36 and 38-42 are on appeal. 
Claims 23, 24, 26-36 and 38-42 are pending. 
Claims 23, 24, 26-36 and 38-42 are rejected. 
Claims 1-22, 25 and 37 are canceled. 

IV. STATUS OF AMENDMENTS 

No Amendment After Final Rejection has been filed. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 
A. Independent Claim 23 

Claim 23 is directed to a method of processing a transaction carried out over a 
network between a financial account holder and a participating entity. FIGURE 1 shows 
a centralized transaction coordinator 10 that administers among other processes an 
online shopping process 300 wherein buyers or consumers engage in online commercial 
transactions with merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the 
coordinator 10 having a presence on the Intemet 50 or another like network. Similarly, a 
buyer 30 (e.g., a financial account holder) and a seller 20 (e.g., a participating entity) also 
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have access to the network 50 over which the transaction is conducted. See page 6, line 
37 through page 7, line 6. 

The claimed method (e.g., the online shopping process 300 administered by the 
coordinator 10) includes receiving a purchase request of a buyer 30 from the 
participating entity (e.g., the seller 20) indicating that the buyer desires to carry out a 
transaction with the entity, the transaction including the buyer purchasing one or more 
selected items. FIGURES 6A and 6B show more detailed flow charts of two 
embodiments of the online shopping process 300. Note, the purchase request 352, in 
accordance with the claimed method, is received by the coordinator 10 and is sent from 
the seller 20. See page 15, lines 20-29. 

The claimed method also includes authenticating the buyer as the financial 
account holder. FIGURES 6A and 6B show the coordinator 10 administering an 
authentication process 310 and making a related determination 320 whether or not the 
buyer is the authentic account holder 30. See page 14, lines 1-10. 

Additionally, the claimed method includes establishing transaction fulfillment 
data, said transaction fulfillment data indicating a delivery destination for the selected 
items, wherein establishing the transaction fulfillment data includes using a previously 
obtained destination as the delivery destination for the selected items when an alternate 
destination is not obtained. FIGURES 6A and 6B show the coordinator 10 establishing 
the transaction fulfillment data at process 360. FIGURE 6C shows a more detailed flow 
chart of an exemplary embodiment of the fulfillment data establishing process 360. 
Suitably, a user (i.e., buyer and/or account holder) pre-registers (e.g., via process 200 
as shown in FIGURES 1 and 4) with the coordinator 10 before using the online 
shopping process 300. During registration 200, optionally, a default delivery destination 
is established for the account holder and maintained by the coordinator 10. See page 
16, lines 16-19. For example, as shown in FIGURE 4, the default delivery destination 
may be supplied by the account holder 30 to the coordinator 10 along with the account 
holder registration data 202 or along with the additional account creation data 226. 

In any event, the coordinator 10 at process 360 established the transaction 
fulfillment data 362 which preferably includes a delivery destination. See page 16, lines 
7-10. Moreover, the previously obtained default destination is used to establish the 
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fulfillment data 362 unless an alternate destination is obtained. See page 16, lines 19- 
25. 

Finally, the claimed method further includes: 

• communicating the transaction fulfillment data to the participating 
entity (FIGURES 6A and 6B show the transaction fulfillment data 362 
being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 17, lines 16-19); 

• receiving transaction details from the participating entity, said 
transaction details including a cost for the selected items (FIGURES 
6A and 6B show the transaction details 384 being received by the 
coordinator 10 from the seller 20 (i.e., the participating entity), see also 
page 17, lines 26-32 identifying the transaction details 384 as including 
a cost for the selected items); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 17, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating entity (FIGURES 6A and 68 show the authorization code 
392 being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

B. Independent Claim 26 

Claim 26 is directed to a method of processing transactions earned out over a 
network between account holders and participating entities. FIGURE 1 shows a central 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the coordinator 10 
having a presence on the Intemet 50 on another like network. Similarly, a buyer 30 (e.g., 
an account holder) and a seller 20 (e.g., a participating entity) also have access to the 



-3- 



Application No.: 09/488,297 



network 50 over which the transaction is conducted. See page 6, line 37 through page 7, 
line 6. 

The claimed method also includes obtaining restriction instructions from account 
holders. Suitably, a user (i.e., buyer and/or account holder) pre-registers (e.g., via 
process 200 as shown in FIGURES 1 and 4) with the coordinator 10 before using the 
online shopping process 300. Upon acceptance of a newly registered account holder, 
the coordinator 10 creates and maintains a record for the account holder 30, e.g., on 
the coordinator's database 14. See FIGURE 1 and page 11, lines 2-9. The account 
holder record includes, among other information, account privileges that restrict 
authorization of transactions in identified circumstances that are set by the account 
holder 30. Suitably, the coordinator 10 obtains the restriction instructions or related data 
that is stored in the coordinator's database 14 by the account holder accessing the 
coordinator's server 12 over the network 50 and customizing or setting their account 
privileges as they desire. See page 1 1 , linesi 0-31 . 

Additionally, the claimed method also includes: 

• receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the 
entity, said transaction including the buyer purchasing one or more 
selected items (FIGURES 6A and 6B show the purchase request 352 
received by the coordinator 10 from the seller 20, see also page 15, 
lines 20-29); 

• authenticating the buyer as an account holder (FIGURES 6A and 6B 
show the coordinator 10 administering an authentication process 310 
and making a related determination 320 whether or not the buyer is 
the authentic account holder 30, see also page 14, lines 1-10); 

• receiving transaction details from the participating entity, said 
transaction details including one or more terms for the purchase 
(FIGURES 6A and 6B show the transaction details 384 being received 
by the coordinator 10 from the seller 20 (i.e., the participating entity), 
see also page 17, lines 26-32); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 68 show the 
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coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 17, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating entity (FIGURES 6A and 6B show the authorization code 
392 being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

C. Independent Claim 31 

Claim 31 is directed to a method of processing transactions carried out over a 
network between account holders and participating entities. FIGURE 1 shows a central 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the coordinator 10 
having a presence on the Intemet 50 on another like network. Similarly, a buyer 30 (e.g., 
an account holder) and a seller 20 (e.g., a participating entity) also have access to the 
network 50 over which the transaction is conducted. See page 6, line 37 through page 7, 
line 6. 

The claimed method includes: 

• receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the 
entity, said transaction including the buyer purchasing one or more 
selected items (FIGURES 6A and 6B show the purchase request 352 
received by the coordinator 10 from the seller 20, see also page 15, 
lines 20-29); 

• authenticating the buyer as an account holder (FIGURES 6A and 6B 
show the coordinator 10 administering an authentication process 310 
and making a related determination 320 whether or not the buyer is 
the authentic account holder 30, see also page 14, lines 1-10); 

• receiving transaction details from the participating entity, said 
transaction details including a cost for the purchase (FIGURES 6A and 
6B show the transaction details 384 being received by the coordinator 
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10 from the seller 20 (i.e., the participating entity), see also page 17, 
lines 26-32 identifying the transaction details 384 as including a cost 
for the selected items); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 17, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating entity (FIGURES 6A and 6B show the authorization code 
392 being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

Additionally, the claimed authorizing step includes: transmitting the transaction 
details of the authenticated account holder to a funding source which determines if the 
account holder has one of sufficient funds on deposit with the funding source or 
sufficient credit available through the funding source to cover the cost of the purchase. 
See, e.g., page 17, line 35 through page 18, line 6, and page 18, lines 11-15. 

D. independent Claim 32 

Claims 32 is directed to method of processing transactions carried out over a 
network between account holders and participating entities. FIGURE 1 shows a central 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the coordinator 10 
having a presence on the Internet 50 on another like network. Similarly, a buyer 30 (e.g., 
an account holder) and a seller 20 (e.g., a participating entity) also have access to the 
network 50 over which the transaction is conducted. See page 6, line 37 through page 7, 
line 6. 

The claimed method includes: 

• receiving a request indicating that a buyer desires to carry out a 
transaction with a participating entity, said transaction including the 
buyer purchasing one or more selected items (FIGURES 6A and 6B 
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show the purchase request 352 received by the coordinator 10 from 
the seller 20, see also page 15, lines 20-29); 

• authenticating the buyer as an account holder (FIGURES 6A and 6B 
show the coordinator 10 administering an authentication process 310 
and making a related determination 320 whether or not the buyer is 
the authentic account holder 30, see also page 14, lines 1-10); 

• receiving transaction details including one or more terms for the 
purchasing the selected items (FIGURES 6A and 6B show the 
transaction details 384 being received by the coordinator 10 from the 
seller 20 (i.e., the participating entity), see also page 17, lines 26-32 
identifying the transaction details 384 as including a cost for the 
selected items); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 17, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating merchant (FIGURES 6A and 68 show the authorization 
code 392 being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

The claimed method also includes obtaining settlement information from the 
participating entity, said settlement information including the authorization code and 
transaction details for the completed transaction. FIGURE 1 shows a settlement 
process 400 also administered by the coordinator 10. See page 6, lines 23-26. FIGURE 
7 shows a more detailed flow chart of the settlement process 400. In particular, 
FIGURE 7 shows the coordinator obtaining settlement information 402 from the seller 
20 for a completed commercial transaction. See page 18, lines 24-27. The obtained 
settlement information 402 preferably includes the authorization code 392 and the 
corresponding transaction details 384 for the completed transaction in question. See 
page 19, lines 9-12. 
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Additionally, the claimed method includes; confirming that the transaction details 
corresponding to the authorization code received with the settlement information are 
within a desired tolerance (see page 19, lines 12-24); and, communicating the 
confirmed settlement information 402b to a funding source 40 to effect reimbursement 
420 of the participating entity (e.g., the seller 20) and billing 410 of the account holder 
30 (see FIGURE 7 and page 19, lines 25-34). 

E. Independent Claim 41 

Claim 41 is directed to a system for processing a transaction carried out over a 
network between a financial account holder and a seller. FIGURE 1 shows a centralized 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the coordinator 10 
having a presence on the Intemet 50 or another like network. Similarly, a buyer 30 (e.g., a 
financial account holder) and a seller 20 (e.g., a participating entity) also have access to 
the network 50 over which the transaction is conducted. See page 6, line 37 through 
page 7, line 6. The coordinator 10 employs a server 12 and/or database 14 as the means 
to carry out the various functions of the online shopping process 300. 

The claimed system includes: 

• means for receiving a purchase request of a buyer from the seller 
indicating that the buyer desires to carry out a transaction with the seller, 
said transaction including the buyer purchasing one or more selected 
items (FIGURES 6A and 6B show the purchase request 352 received by 
the coordinator 10 from the seller 20, see also page 15, lines 20-29, and 
FIGURE 2 shows the coordinator's server 12 interconnected for 
communication via the network 50 with the seller's server 22 thereby 
providing the server 12 as the means to achieve the forgoing function); 

• means for authenticating the buyer as the financial account holder 
(FIGURES 6A and 6B show the coordinator 10 administering an 
authentication process 310 and making a related determination 320 
whether or not the buyer is the authentic account holder 30, see also 
page 14, lines 1-10, and FIGURE 2 shows the coordinator's server 12 
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interconnected for communication via the network 50 with the buyer's 
computer 32 thereby providing the server 12 as the means to achieve the 
forgoing function); 

means for establishing transaction fulfillment data, said transaction 
fulfillment data indicating a delivery destination for the selected items 
(FIGURES 6A and 6B show the coordinator 10 at process 360 
establishing the transaction fulfillment data 362 which preferably includes 
a delivery destination, see also page 16, lines 7-10, FIGURE 2 shows the 
server 12 and/or database 14 employed by the coordinator 10 that 
administers the online shopping process 300 thereby providing the means 
to achieve the forgoing function, e.g., the server 12 provides for 
communication with the buyer 30 from which an alternate delivery 
destination is optionally received (see FIGURE 6C showing the process 
360 administered by the coordinator 10 including an option for delivery 
destination selection by a buyer, and FIGURE 2 showing the 
interconnection of the coordinator's server 12 and the buyer's computer 
32 via the network 50 for communication therebetween), and the 
database 14 provides for storage of a default delivery address that may 
be employed to establish the transaction fulfillment data (see FIGURE 2 
and page 16, lines 16-19 and page 11, lines 2-4)); 

means for communicating the transaction fulfillment data to the seller 
(FIGURES 6A and 6B show the transaction fulfillment data 362 being sent 
from the coordinator 10 to the seller 20, see also page 17, lines 16-19, 
and FIGURE 2 shows the coordinator's server 12 interconnected for 
communication via the network 50 with the seller's server 22 thereby 
providing the server 12 as the means to achieve the forgoing function); 
nieans for receiving transaction details from the seller, said transaction 
details including a cost for the selected items (FIGURES 6A and 6B show 
the transaction details 384 being received by the coordinator 10 from the 
seller 20, see also page 17, lines 26-32 identifying the transaction details 
384 as including a cost for the selected items, and FIGURE 2 shows the 
coordinator's server 12 interconnected for communication via the network 
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50 with the seller's server 22 thereby providing the server 12 as the 
means to achieve the forgoing function); 

• means for authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the coordinator 
10 executing an authorization process 390 that establishes an 
authorization code 392, see also page 17, lines 27-29, page 17, line 35 
through 18, line 6, and page 18, lines 12-15, and FIGURE 2 shows the 
server 12 and/or database 14 employed by the coordinator 10 that 
administers the online shopping process 300 thereby providing the means 
to achieve the forgoing function); and, 

• means for communicating the authorization code for the transaction to the 
seller (FIGURES 6A and 6B show the authorization code 392 being sent 
from the coordinator 10 to the seller 20, see also page 18, lines 20-23, 
and FIGURE 2 shows the coordinator's server 12 interconnected for 
communication via the network 50 with the seller's server 22 thereby 
providing the server 12 as the means to achieve the forgoing function). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The following grounds of rejection are presented for review: 
Claims 41 and 42 stand rejected under 35 U.S.C. §112, second paragraph, as 
being indefinite; 

Claims 23, 24, 26-28, 31-34 and 36-40 stand rejected under 35 U.S.C. §102(b) 
as being anticipated by U.S. Patent No. 4,799,156 to Shavit, et al. (hereinafter merely 
referred to as Shavit); and, 

Claims 29 and 30 stand rejected under 35 U.S.C. §1 03(a) as being unpatentable 
over Shavit in view of U.S. Patent No. 5,826,245 to Sandber-Diment. 

VIL GROUPING OF CLAIMS 

Claims 23, 24, 26-28, 31-34 and 36-40 do not stand or fall together. The 
independent claims 23, 26, 31 and 32 are separately patentable from one another. 
Accordingly, claims 23, 24 and 36 stand or fall on their own; claims 26-30 and 38 stand 
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or fall on their own; claims 31 and 39 stand or fall on their own; and, claims 32-35 and 
40 stand or fall on their own. 

VIII. ARGUMENTS 

Initially, a brief summary of the procedural history of the application will be 
presented insomuch as the Applicants deem it to be informative and/or relevant to the 
weakness of the rejections sought to be reviewed. 

After filing the application, Applicants received a first non-final Office Action on 
the merits (i.e., paper No. 9) indicating allowable subject matter in the originally 
presented claims 23-28 and 31-33. Supervisory Patent Examiner Vincent Millin singed- 
off on the first non-final Office Action. Thereafter, Applicants arranged for an Examiner 
Interview with Examiner Sandra Snapp (i.e., the examiner assigned to examine the 
application). Prior to the interview. Examiner Snapp was faxed proposed claim 
amendments. Independent claims 23, 26, 31 and 32 as they currently stand are 
essentially the same as if not identical to those proposed prior to the interview. Notably, 
in the Interview Summary (i.e., paper No. 10) which Examiner Snapp prepared and 
signed herself following the interview, she again expresses clearly that the proposed 
claims "were identified as being allowable over the prior art of record." Shavit and 
Sandber-Diment were both references of record prior to the first Office Action and the 
interview. Importantly, the fact that the current rejections are ultimately untenable is 
further underscored by the fact that on prior occasions, after having had ample 
opportunity to reject the claims based upon references of record already before them, 
apparently both Examiner Snapp and Supervisory Examiner Millin were convinced of 
the allowable nature of the claims over the references upon which the present prior art 
rejections are now based. 

A. Claims 41 & 42 Are Not Indefinite 

The final Office Action (mail date January 12, 2005) alleges that claims 41 and 
42 are indefinite and hence rejected under 35 U.S.C. §112, second paragraph. The 
alleged grounds for the rejection is that the claims are directed to a "system" and can 
therefore "be interpreted to be an apparatus or a method." This position is however 
untenable and the rejection should be reversed. 
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While indeed the preamble of the claims recite a system, the term system is not 
in and of itself indefinite. Moreover, each and every element in the body of the 
independent claim 41 is described using means-plus-function language. Clearly, the 
claim elements are means and not steps, and clearly the claim is directed to an 
apparatus including the claimed means and not a method including steps. In this way, 
claim 41 particularly points out and distinctly claims the subject matter which Applicants 
regard as their invention. Claim 42 depends from claim 41 and is accordingly also 
clearly directed to an apparatus. 

Contrary to the allegation in the final Office Action, claims 41 and 42 are definite 
and clearly directed to an apparatus as evident from the claimed elements. The 
piecemeal dissection of a selected term from the preamble of the claim and its review 
out of context from the rest of the claim is inappropriate and erroneous. It is well settled 
that "in reviewing a claim for compliance with 35 U.S.C. §112, second paragraph, the 
examiner must consider the claim as a whole." Manual of Patent Examining Procedure 
(MPEP) §2173.02. In this case, the claim as a whole is not render indefinite simply 
because the claim recites a "system" in the preamble. When considered as a whole 
(i.e., including the claimed elements in the body of the claim), the claim is clearly 
directed to an apparatus. Any alleged confusion as to the meaning of the claims on the 
part of the examiner is disingenuous and specious. 

Accordingly, for at least the reasons outlined above, the rejection of claims 41 
and 42 under 35 U.S.C. §112, second paragraph, is in error and should be reversed. 
Moreover, having no other outstanding rejections or objections, claims 41 and 42 
should be held allowed. 

B. Brief Summary of the Shavit Reference 

Shavit is directed to creating an artificial industry-based market place whereby 
distributors, buyers and other market participants in a particular industry can meet and 
interactively transact business. Unlike the current application, the participants 
transacting together are concurrently logged-in to the system to access one another's 
data. Essentially, the Shavit system merely acts as a conduit to connect respective 
parties that wish to transact business together by providing an electronic mail system 
that distributes mail messages (e.g., orders, bids, delivery advisories, etc.) to the 
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respective parties. The transaction details are negotiated between the participants 
themselves. In effect, the Shavit system is not processing the transaction at all, but 
rather, is merely passing messages back and forth. On the contrary, in the present 
application, the transaction is actually processed by the third party centralized 
coordinating entity/system, i.e., it authenticates the buyer, establishes transaction 
fulfillment data, authorizes completion of the transaction, etc. 

C. General Arguments Regarding the Rejections Based on Shavit 

Generally, the rejections based on Shavit are erroneous and should be reversed 
insomuch as Shavit fails to anticipate the claimed subject matter. The MPEP is 
instructive on this point. According to MPEP §2131, to anticipate a claim under 35 
U.S.C. §102, "the reference must teach every element of the claim" and "the identical 
invention must be shown in as complete detail as is contained in the ... claim" and "the 
elements must be arranged as required by the claim." [Citations omitted]. Importantly, 
Shavit does not teach the claimed elements arranged as required. Applicants note that 
the grounds for rejection based upon Shavit take unrelated passages out of context 
from various diverse parts of the reference, and they are recombined capriciously in an 
attempt to read on the claimed invention. The reference simply does not contemplate 
such a random reconstruction of its elements. In rejecting the claims, seemingly 
unrelated text is cite from all over the reference. For example, an impermissible 
piecemeal rejection of the claims is supported by citing to various disconnected and 
unrelated passages of text which allegedly disclose the claimed elements/steps. That is 
to say, it is alleged that col. 6, lines 36-39 teaches one element; while col. 9, line 60 
though col. 10, line 15, teaches another; col. 14, lines 28-33 teaches yet another; col. 
13, lines 35-50 teaches still another element; and, so on. Clearly, this is an 
impermissible rearranging of the teachings of Shavit to meet the claims in a way not 
contemplated by the reference. Shavit simply does not teach the claimed invention, 
because it is not directed to the same type of claimed transaction processing 
application, but is rather directed to merely creating an artificial market place. 
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D. Claim 23 is Not Anticipated by Shavit 

Shavit fails to anticipate independent claim 23 insomuch as Shavit does not 
explicitly teach or fairly suggest all of the claimed elements. Claim 23 calls for "receiving 
a purchase request ... from the participating entity indicating that the buyer desires to 
carry out a transaction with the entity, said transaction including the buyer purchasing 
one or more selected items." The Examiner cites col. 6, lines 36-39 as disclosing this 
element. However, the cited passage teaches nothing of the sort. Rather, the cited text 
merely states that "a distributor may offer its customer an interactive, convenient and 
consistent way to place orders or conduct any other business with the distributor." 
Notably, in Shavit, it is never expressly taught that the IMM 50 receives a purchase 
request (i.e., an order) from a distributor or selling party. Purchase orders are 
apparently delivered from subscribing buyers to distributors. They are not received by 
the system 50. Moreover, the purchase orders are placed by the subscribing buyer. 
Accordingly, if the system 50 where to receive them from anyone, it would be from the 
subscribing buyer, not the entity or seller filling the order. This is contrary to the claim 
which recites that the purchase request is received from the participating entity, i.e., the 
entity from which the buyer is purchasing the item, e.g., the seller (or the distributor in 
the case of Shavit). 

Notably, FIGURE 3 shows the buyer transaction function in accordance with the 
teachings of Shavit. See, col. 2, lines 51-55. More specifically, the procurement process 
124 of FIGURE 3 is illustrated in greater detail in FIGURE 14 which shows the 
purchase order entry process 336. See, col. 3, lines 41-45. Accordingly, the purchase 
order entry process 336 is part of the buyer transaction function. In the purchasing 
function, orders are entered by the buyer. See col. 25, lines 58-59. In any event, 
nowhere is it taught by Shavit that the purchase orders are received by the IMM system 
50 from distributors or sellers or other like situated entities. Conversely, in the present 
application the coordinator 10 receives the purchase request from the seller 20 not the 
buyer 30. 

Claim 23 calls for "authenticating the buyer as the financial account holder." 
Shavit also fails to expressly teach or fairly suggest this feature. The Examiner cites col. 
9, line 60 through col. 10, line 15 as disclosing this feature. However, the cited text 
does not disclose the claimed authentication. The cited passage merely describes how 
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a subscribing user logs-in to and/or accesses the IMM system 50. Nowhere does it 
even suggest that the subscribing user is authenticated by the IMM system 50 as the 
holder of any kind of financial account as claimed. 

Claim 23 further calls for "establishing transaction fulfillment data, said 
transaction fulfillment data indicating a delivery destination for the selected items, 
wherein establishing the transaction fulfillment data includes using a previously 
obtained destination as the delivery destination for the selected items when an alternate 
destination is not obtained." Again, Shavit fails to disclose this element/step. The 
Examiner cites col. 14, lines 28-33 as disclosing this element/step. However, the cited 
text does not disclose the claimed establishment of transaction fulfillment data. The 
cited text reads, "The distributor normally delivers an order to the bu/s site, however, it 
is possible to take delivery in the distributor's, the agent's, or the manufacturer's 
warehouse. The system, therefore, provides extensive services to allow reservation and 
control of freight services." Nowhere does this passage suggest that the IMM system 50 
establishes any transaction fulfillment data. It only suggests that the delivery site may 
be at a number of exemplary locations other than the buy's site, and that a mechanism 
is provided to select the delivery location. This does not mean that the IMM system 50 
is establishing the transaction data as claimed. 

In the present application the fulfillment data is established by the coordinator 
10, e.g., retrieving a previously obtained destination from the database 14 when no 
alternate destination is selected by the buyer. Nowhere does Shavit teach that the IMM 
50 establishes the transaction fulfillment data using a destination previously obtained by 
the IMM system 50. Rather, Shavit merely suggests that the buyer may select different 
delivery destinations. Moreover, freight service operations 132 are handled separately 
and distinctly from the procurement process 124. See FIGURE 3. Note, the freight 
service reservation process 462 is shown in FIGURE 19 which details freight service 
operations 132 and not in FIGURE 14 which details procurement operations 124 (i.e., 
including purchases). Accordingly, freight service and/or delivery instructions are 
handled outside and separately from the purchase process. 

Additionally, claim 23 calls for "receiving transaction details from the participating 
entity, said transaction details including a cost for the selected items; authorizing 
completion of the transaction and establishing an authorization code therefor; and. 
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communicating the authorization code for the transaction to the participating entity." 
The Examiner cites col. 13, lines 35-50 as teaching the foregoing. In fact, however, the 
cited passage does not teach this. In particular, the text discloses that a distributor and 
buyer negotiate a purchase agreement fixing a price for goods. The terms of the 
agreement, and hence the transaction, is therefore authorized by the seller. 

The IMM system 50 does not authorize completion of the transaction as claimed 
nor does the IMM system 50 establish an authorization code. In fact, nowhere is an 
authorization code even mentioned. Conversely, in the present application, the 
coordinator 10 (not the seller) authorizes completion of the transaction and establish 
the authorization code therefor. 

For the reasons outlined above, claim 23 defines patentably over Shavit, along 
with claims 24 and 36 that depend therefrom. Accordingly, the rejection of claims 23, 24 
and 36 under 35 U.S.C. §1 02(b) is in error and should be reversed. Moreover, having 
no other outstanding rejections or objections, these claims should be held allowed. 

E. Claims 26 & 28 Are Not Anticipated by Shavit 

Shavit fails to anticipate independent claim 26 insomuch as Shavit does not 
explicitly teach or fairly suggest all of the claimed elements. Moreover, Shavit fails to 
anticipate claim 28 insomuch as Shavit does not explicitly teach or fairly suggest the 
further refinements and/or features recited in claim 28 which depends from claim 26. In 
particular, claim 26 recites "obtaining restriction instructions from account holders" and 
claim 28 recites "wherein said restriction instructions block authorizing the completion of 
recurring transactions which are not separately participated in by the account hold from 
whom the restriction instructions were obtained." Shavit teaches no such features. The 
Examiner cites col. 6, lines 52-68 as disclosing the claimed subject matter. However, 
this passage has nothing to do with restricting automatically recurring transactions. In 
fact, the cited text make no mention of obtaining restriction instructions or blocking the 
completion of any transactions. Accordingly, claim 26 further defines patentably over 
the reference along with the claims depending therefrom, and in particular claim 28. 

Claim 26 also calls for "receiving a purchase request ... from the participating 
entity indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items." Shavit teaches 
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nothing of the sort. Rather, Shavit merely teaches that a distributor may offer its 
customer an interactive, convenient and consistent way to place orders or conduct any 
other business with the distributor. Notably, Shavit never expressly discloses that the 
IMM 50 receives a purchase request (i.e., an order) from a distributor or selling party. 
This is contrary to the claim which recites that the purchase request is received from the 
participating entity, i.e., the one from which the purchase is being made, e.g., the seller 
(or the distributor in the case of Shavit). 

Additionally, claim 26 also calls for "receiving transaction details from the 
participating entity, said transaction details including one or more terms for the 
purchase; authorizing completion of the transaction and establishing an authorization 
code therefor; and, communicating the authorization code for the transaction to the 
participating entity." Shavit, however, does not teach this. In Shavit, e.g., a purchase 
agreement fixing a price for goods is negotiated directly between a distributor/seller and 
buyer. The terms of the agreement, and hence the transaction, is therefore authorized 
by the seller. The IMM system 50 does not authorize completion of the transaction as 
claimed nor does the IMM system 50 establish an authorization code. 

For the reasons outlined above, claim 26 defines patentably over Shavit, along 
with claims 27-30 and 38 that depend therefrom. Accordingly, the rejection of claims 26- 
28 and 38 under 35 U.S.C. §1 02(b) and the rejection of claims 29 and 30 under 35 
U.S.C. §1 03(a) are in error and should be reversed. Moreover, having no other 
outstanding rejections or objections, these claims should be held allowed. 

F. Claim 31 is Not Anticipated by Shavit 

Claim 31 calls for "receiving a purchase request ... from the participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items." Shavit, as 
already pointed out, does not teach this element. Rather, Shavit merely teaches that "a 
distributor may offer its customer an interactive, convenient and consistent way to place 
orders or conduct any other business with the distributor." Notably, in Shavit, it is never 
expressly taught that the IMM system 50 receives a purchase request (i.e., an order) 
from a distributor or selling party. If at all, the IMM system 50 receives purchase orders 
from the subscribing buyer, not the entity or seller filling the order. This is contrary to the 
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claim which recites that the purchase request is received from the participating entity, 
i.e., the one from which the purchase is being made, e.g., the seller (or the distributor in 
the case of Shavit). 

Additionally, claim 31 also calls for "receiving transaction details from the 
participating entity, said transaction details including a cost for the purchase; 
authorizing completion of the transaction and establishing an authorization code 
therefor and, communicating the authorization code for the transaction to the 
participating entity." Shavit, as previously noted, does not teach this. In Shavit, a 
distributor and buyer negotiate a purchase agreement fixing a price for goods. The 
terms of the agreement, and hence the transaction, is therefore authorized by the 
seller. The IMM system 50 does not authorize completion of the transaction as claimed 
nor does the IMM system 50 establish an authorization code. As already noted, 
nowhere is an authorization code even mentioned. 

Moreover, claim 31 further calls for authorizing completion of the transaction and 
establishing an authorization code to include "transmitting the transaction details of the 
authenticated account holder directly to a funding source which determines if the 
account holder has one of sufficient funds on deposit with the funding source or 
sufficient credit available through the funding source to cover the cost of the purchase; 
and, receiving the authorization code from the funding source." Contrary to the 
Examiner's allegation, Shavit also fails to expressly teach this feature. Nevertheless, 
col. 26, line 29 through col. 27, line 30 is cited as disclosing this feature. However, the 
cited text merely describes a "procurement process" that "permits the buyer to instruct 
its bank to pay a bill or group of bills to a distributor or other payees, based on 
agreements between the buyer, the payee and the buyer's bank." Again, the 
transaction is carried out by the parties themselves based upon a predetermined 
agreement, and there is no mention at ali of any authorization code. This is not what is 
being claimed. 

For the reasons outlined above, claim 31 defines patentably over Shavit, along 
with claim 39 that depends therefrom. Accordingly, the rejection of claims 31 and 39 
under 35 U.S.C. §1 02(b) is in error and should be reversed. Moreover, having no other 
outstanding rejections or objections, these claims should be held allowed. 
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G. Claim 32 is Not Anticipated by Shavit 

Claim 32 calls for "receiving a request indicating that a buyer desires to carry out 
a transaction with a participating entity, said transaction including the buyer purchasing 
one or more selected items; authenticating the buyer as an account holder; receiving 
transaction details including one or more terms for the purchasing the selected items; 
authorizing completion of the transaction and establishing an authorization code 
therefor; and communicating the authorization code for the transaction to the 
participating merchant." As already noted above, Shavit fails to explicitly teach or fairly 
suggest any of the foregoing elements as claimed. 

Additionally, claim 32 includes elements directed and/or related to transaction 
settlement. More specifically, claim 32 calls for "obtaining settlement information from 
the participating entity, said settlement information including the authorization code and 
transaction details for the completed transaction; confirming that the transaction details 
corresponding to the authorization code received with the settlement information are 
within a desired tolerance; and, communicating the confirmed settlement information to 
a funding source to effect reimbursement of the participating entity and billing of the 
account holder." Shavit also fails to disclose the foregoing elements. Notably, the 
Examiner never even alleges that Shavit teaches the claimed confirming of the 
transaction details or the claimed communicating of confirmed settlement information to 
a funding source. 

Notably, the payment process 344 (shown in FIGURE 14 and in greater detail in 
FIGURE 15) is part of the procurement procedure 124 shown in FIGURE 3 as an option 
for a buyers transaction. Accordingly, the processing of payment instructions are 
initiated by the buyer. Nowhere in this process is it suggested that the IMM system 50 
obtains settlement information (including an authorization code and transaction details) 
from a seller, nor that transaction details are confirmed by the IMM system 50. Finally, 
per box 376 of FIGURE 15, Shavit merely disclose issuing payment orders. This is not 
the same a providing the funding source with confirmed settlement information. 
Nowhere does Shavit suggest that the payment orders anywhere indicated that any 
information has been confirmed or that the information in the payment order includes 
even settlement information. For example, Shavit arguably contemplates no more than 
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communicating to a financial institution an instruction to pay a given seller a sum of 
money from a given account. 

For the reasons outlined above, claim 32 defines patentably over Shavit, along 
with claims 33-35 and 40 that depend therefrom. Accordingly, the rejection of claims 32- 
35 and 40 under 35 U.S.C. §1 02(b) is in error and should be reversed. Moreover, 
having no other outstanding rejections or objections, these claims should be held 
allowed. 

H. Claims 23, 26, 31 and 32 are Separately Patentable 

Claim 23, 26, 31 and 32 are all separately patentable from one another. Notably, 
each claim is an independent claim distinct and standing alone from the others. Clearly, 
as independent claims not depending on or referencing the others, each of the claims 
stands or falls on its own merits. Moreover, the scope of the claims are different from 
one another. When comparing each independent claim to the other independent claims, 
there are mutually distinct elements claimed that create a separately patentable 
difference between them. Moreover, these different elements define the claims 
patentably over the art. 

For example, claim 23 includes an element directed to establishing transaction 
fulfillment data that is absent from the other independent claims. Accordingly, claim 23 
is separately patentable from the other claims insomuch as they are not of the same 
scope, they are mutually independent and they claim different elements. Similarly, claim 
26 includes an element directed to obtaining restriction instructions from account 
holders that is absent from the other independent claims. Accordingly, claim 26 is 
separately patentable from the other claims insomuch as they are not of the same 
scope, they are mutually independent, and they claim different elements. 

Claim 31 includes elements directed to transmitting the transaction details of the 
authenticated account holder to a funding source and receiving the authorization code 
from the funding source. These elements are absent from all the other claims and they 
create a substantive distinction therewith. Accordingly, claim 31 is separately patentable 
from the other claims insomuch as they are not of the same scope, they are mutually 
independent, and they claim different elements. 
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Finally, claim 32 includes elements (f), (g) and (h) related to settlement of a 
transaction. All these elements are absent from all the other claims and they create a 
substantive distinction therewith. Accordingly, claim 32 is separately patentable from 
the other claims insomuch as they are not of the same scope, they are mutually 
independent, and they claim different elements. 

IX- CONCLUSION 

For all of the reasons discussed above, it is respectfully submitted that the 
rejections are in error and that all the claims remaining are in condition for allowance. 
For all of the above reasons, Appellants respectfully request this Honorable Board to 
reverse the rejections of all the remaining claims. 
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CLAIMS APPENDIX 

Claims involved in the appeal: 
1-22. (Cancelled). 

23. (Previously Presented) A nnethod of processing a transaction 
carried out over a network between a financial account holder and a participating entity, 
said method comprising the steps of: 

(a) receiving a purchase request of a buyer from the participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items; 

(b) authenticating the buyer as the financial account holder; 

(c) establishing transaction fulfillment data, said transaction fulfillment 
data indicating a delivery destination for the selected items, wherein establishing the 
transaction fulfillment data includes using a previously obtained destination as the 
delivery destination for the selected items when an alternate destination is not obtained; 

(d) communicating the transaction fulfillment data to the participating 

entity; 

(e) receiving transaction details from the participating entity, said 
transaction details including a cost for the selected items; 

(f) authorizing completion of the transaction and establishing an 
authorization code therefor; and, 

(g) communicating the authorization code for the transaction to the 
participating entity. 

24. (Original) The method according to claim 23, wherein 
establishing the fulfillment data further includes: 

obtaining an alternate destination from the buyer, said alternate 
destination being different from the previously obtained destination; 
transmitting a security question to the buyer; 
receiving a response to the security question from the buyer; and, 
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using the alternate destination as the delivery destination for the selected 
items when the response to the security question is accurate. 

25. (Cancelled). 

26. (Previously Presented) A method of processing transactions 
carried out over a network between account holders and participating entities, said 
method comprising the steps of: 

(a) obtaining restriction instructions from account holders; 

(b) receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items; 

(c) authenticating the buyer as an account holder; 

(d) receiving transaction details from the participating entity, said 
transaction details including one or more terms for the purchase; 

(e) authorizing completion of the transaction and establishing an 
authorization code therefor; and, 

(f) communicating the authorization code for the transaction to the 
participating entity. 

27. (Previously Presented) The method according to claim 26, 
wherein said restriction instructions block authorizing the completion of transactions 
with participating entities identified in the restriction instructions. 

28. (Original) The method according to claim 26, wherein said 
restriction instructions block authorizing the completion of recurring transactions which 
are not separately participated in by the account holder from whom the restriction 
instructions were obtained. 

29. (Previously Presented) The method according to claim 26, 
wherein authorizing completion of the transaction includes comparing a cost of the 
selected items to a threshold such that if the cost is less than or equal to the threshold 
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authorization is given and if the cost if greater than the threshold authorization is 
denied. 

30. (Previously Presented) The method according to claim 29, 
wherein the threshold represents an amount selected from a group consisting of funds 
on deposit for the account holder, credit available to the account holder, and a value set 
via the obtained restriction instructions. 

31. (Previously Presented) A method of processing transactions 
carried out over a network between account holders and participating entities, said 
method comprising the steps of: 

(a) receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items; 

(b) authenticating the buyer as an account holder; 

(c) receiving transaction details from the participating entity, said 
transaction details including a cost for the purchase; 

(d) authorizing completion of the transaction and establishing an 
authorization code therefor, wherein authorizing completion of the transaction and 
establishing an authorization code therefor includes: 

transmitting the transaction details of the authenticated 
account holder directly to a funding source which determines if the 
account holder has one of sufficient funds on deposit with the funding 
source or sufficient credit available through the funding source to cover 
the cost of the purchase; and, 

receiving the authorization code from the funding source; 

and, 

(e) communicating the authorization code for the transaction to the 
participating entity. 
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32. (Previously Presented) A method of processing transactions 
carried out over a network between account holders and participating entities, wherein 
said method comprises: 

(a) receiving a request indicating that a buyer desires to carry out a 
transaction with a participating entity, said transaction including the buyer purchasing 
one or more selected items; 

(b) authenticating the buyer as an account holder; 

(c) receiving transaction details including one or more terms for the 
purchasing the selected items; 

(d) authorizing completion of the transaction and establishing an 
authorization code therefor; 

(e) communicating the authorization code for the transaction to the 
participating merchant; 

(f) obtaining settlement information from the participating entity, said 
settlement information including the authorization code and transaction details for the 
completed transaction; 

(g) confirming that the transaction details corresponding to the 
authorization code received with the settlement information are within a desired 
tolerance; and, 

(h) communicating the confirmed settlement information to a funding 
source to effect reimbursement of the participating entity and billing of the account 
holder. 

33. (Previously Presented) The method according to claim 32, 
wherein obtaining the settlement information includes automatically capturing the 
settlement information from the participating entity upon an indication of delivery of the 
selected items. 

34. (Previously Presented) The method according to claim 32, 
wherein step (b) precedes step (a). 
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35. (Previously Presented) The method according to claim 32, 
wherein authenticating the buyer as an account holder includes: 

synchronizing a token with a periodically changing non-predictable code; 

providing the account holder with the token, said token displaying the 
periodically changing non-predictable code; 

receiving a code communicated by the buyer; and, 
comparing the received code with the periodically changing non-predictable code to 
authenticate the buyer as the account holder when the received code matches the 
periodically changing non-predictable code. 

36. (Previously Presented) The method according to claim 23, 
wherein the transactions are at least partially carried out over a public network. 

37. (Cancelled). 

38. (Previously Presented) The method according to claim 26, 
wherein the transactions are at least partially carried out over a public network. 

39. (Previously Presented) The method according to claim 31, 
wherein the transactions are at least partially carried out over a public network. 

40. (Previously Presented) The method according to claim 32, 
wherein the transactions are at least partially carried out over a public network. 

41. (Previously Presented) A system for processing a transaction 
carried out over a network between a financial account holder and a seller, said system 
comprising: 

means for receiving a purchase request of a buyer from the seller 
indicating that the buyer desires to carry out a transaction with the seller, said 
transaction including the buyer purchasing one or more selected items; 

means for authenticating the buyer as the financial account holder; 
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means for establishing transaction fulfillment data, said transaction 
fulfillment data indicating a delivery destination for the selected items; 

means for communicating the transaction fulfillment data to the seller; 

means for receiving transaction details from the seller, said transaction 
details including a cost for the selected items; 

means for authorizing completion of the transaction and establishing an 
authorization code therefor; and, 

means for communicating the authorization code for the transaction to the 

seller. 



42. (Previously Presented) The system according to claim 41, 
wherein the transactions are at least partially carried out over a public network. 



